1. Field of the Invention
The invention generally relates to Web applications, and more particularly relates to a method and system for providing a runtime vulnerability defense for cross domain interactions for a Web application.
2. Description of Related Art
A Web application is defined as a Web-based application which means any application program for which the user interface resides in a Web browser. It is a collection of particular web pages and other resources for completing specific tasks. A Web application is a product of client/server architecture. It enables a client and a server to communicate with each other over a network. The common message boards, chat rooms, and bulletin board systems (BBS) are all Web applications. These applications, however, are relatively simple. The real core function of a Web application is to handle data.
Recently, along with the development of Software-as-a-Service (SaaS) applications, there is a need to combine contents from multiple sources, which reside in different domains, into an integrated content. An SaaS application is a kind of Web application. It is an innovative software application mode that is gradually developed along with Internet technologies and the maturing of application programs.
SaaS is a method of software supply over the Internet, in which a supplier makes a unified deployment of application software on its own server. A user can subscribe to a required application software service by way of a supplier over the Internet based on the user's actual requirement, make payment to the supplier according to the extent and time length of the subscribed service, and acquire the service offered by the supplier over the Internet. It is not necessary for the user to purchase software. Instead, the user hires Web-based software from the supplier to manage enterprise business operations. The user does not need to maintain software. Such software will be managed and maintained by the supplier. Simultaneously with providing Internet applications to customers, the supplier also provides off-line operations for software and local data storage in order to enable the user to utilize his subscribed software and service at any time and any place.
In the context of a Web application like an SaaS application, there is always a need to combine contents from multiple sources. For example, in a Sales Force Automation (SFA) application, there can be a need to integrate contact management information from another server into the application. Here, cross domain content interaction is required. In practice, since an SaaS application often needs to combine data from other sources residing in different domains, it will have to make a choice between security and functionality. In some traditional approaches, the considerations for security often relate to the approaches listed below. However, each has its own limitations.
Input validation: The function of input validation is mainly to filter user-inputted values based on pre-defined patterns. If, however, a user gets the content directly from a third party service, the input validation function will be bypassed, such that a potential and malicious attack from the content cannot be prevented.
Browser-side plug-in: A browser-side plug-in, such as a Flash plug-in, can support communications between various domains and provide multiple cross domain capabilities. However, for the sake of security, privacy, or compatibility, some users do not want to install a browser-side plug-in.
Server-side proxy: A server-side proxy filters data from a third party server, and makes the data appear to be same-origin data to the client side. Thus, the browser can first connect to the proxy to retrieve third party contents. A disadvantage of this approach is that it increases latency when connecting to the third party server through the proxy.
Fragment identifier messaging: Some approaches can utilize fragment identifiers to implement cross domain communication. Such approaches append #message to the end of a Uniform Resource Locator (URL) for transmitting a message. A disadvantage of such approaches is that the communication can be easily disrupted when a user clicks on the browser's “back” button. Further, there is a length constraint for the message to be transmitted.
In many current Web applications, the cross domain interaction is performed with an AJAX-based rich Web application. The term AJAX is a shortening of “Asynchronous JavaScript+XML.” The core of AJAX, a JavaScript object XmlHttpRequest, supports asynchronous requests. In brief, the object XmlHttpRequest allows client-side JavaScript scripts to make a request to the server and process the response, without refreshing the page in the browser and without blocking the user.
The detailed definition and description of the object XmlHttpRequest can be referred to the specification of World Wide Web Consortium (W3C), at the Web address http://www.w3.org/TR/XMLHttpRequest. However, in consideration of security, an AJAX-based rich Web application can only access resources in the current domain where the application is located, and cannot implement cross domain access. This is referred to as the policy of same-origin constraint. For example, an AJAX in a site domain1.com can only access resources in that site, and cannot make a cross domain access to resources in a site domain2.com. In SaaS applications, however, a Web application belonging to some domain sometimes needs to make an AJAX request to a server belonging to another domain, in order to invoke services or resources on the server. The above-stated cross domain access is subject to the constraint of the existing XMLHttpRequest implementations.
A rich Web application can also provide a new service, which returns a response in the format of JavaScript Object Notation (JSON) instead of XML. JSON is a lightweight computer data interchange format. It is a text-based, human-readable format for representing simple data structures and associative arrays or objects. The JSON format is often used for transmitting structured data over a network connection. JSON can be created in the following two structures: a set of “name/value” pairs, which can be considered as object, record, structure, dictionary, hash table, keyed list, associative array; or an ordered value list. In most languages, it is configured in array form. Therefore, it is possible to exchange the same data format between programming languages that are based on the same structures.
In fact, if a Web service request is made with a dynamic script tag approach, and a JavaScript callback function is specified, then it is possible to implement free access to Web services in a seamless, cross-site manner. In this regard, JSON with padding (JSONP) is proposed to act as a standard for obtaining JSON from an external domain, where a callback function is specified as an input variable of the call itself. However, there is a security problem with JSONP when retrieving data from a third party service, since it cannot prevent a malicious attack by the third party data.
For example, FIG. 1 illustrates an exemplary diagram of a Web application performing a vulnerability attack for a cross domain interaction with JSONP. As shown in FIG. 1, a hosting server 100 communicates with a client browser 110. The client browser 110 communicates with a third party server 120, where the hosting server 100 hosts Web applications to be performed on the client browser 110. Thus, the hosting server 100 submits a request 130 to the third party server 120 for accessing third party contents through the client browser 110.
In the request 130, a callback function, getConInfo, is specified and defined for presenting to a user the information provided by the third party server 120. The information in this example is contact information. This callback function refers to a function that can be used by the third party server 120 in the returned response 140. In a normal circumstance, the third party server 120 provides the user with the contact information in the format of JSON with the specified callback function, getConInfo. Then, the browser 110 can receive and read the information in the format of JSON, and present the information to the user in the form specified in the callback function.
In practice, the approach is vulnerable to malicious attacks. In one circumstance, as shown in the upper part of the response 140 in FIG. 1, a malicious attacker can append some malicious codes to the normal contact information, which is located between <script> and </script>. In this way, when the client browser 110 receives the response information and performs the callback function, the malicious codes will be performed at the same time, so that the client is at risk.
For example, sensitive information of the client can be revealed, or malicious scripts can be embedded into the client. In another circumstance, as shown in the lower part of the response 140 in FIG. 1, a malicious attacker can define a new function in the response information. The function shown has the same name as the callback function, getConInfo. The malicious attacker can embed malicious scripts, located between <script> and </script>, into the new function. In this way, when the client browser 110 receives the response information and performs the callback function, the new function defined by the malicious attacker, instead of the callback function defined by the client, will actually be performed, so that the client is at risk.
It can be seen from the above analysis that the various approaches to the problem of Web application vulnerability have disadvantages in that they cannot satisfy the requirements of both security and functionality simultaneously. Thus, to enable Web applications, especially SaaS applications, to interact with other domains for obtaining and incorporating data from other domains while taking sufficient security into account, there is a need for a method and system for providing a runtime vulnerability defense for cross domain interactions for Web applications.